The software industry increasing relies on methods for checking and refining software code. “Software Inspections are a disciplined engineering practice for detecting and correcting defects in software artifacts, and preventing their leakage into field operations. Software Inspections were introduced in the 1970s at IBM, which pioneered their early adoption and later evolution. Software Inspections provide value in improving software reliability, availability, and maintainability.” [Fagan, M. “Design and Code Inspections to Reduce Errors in Program Development.” IBM Systems Journal 15, 3 (1976): 182-211].
Many software inspection tools for identifying software defects are currently in use. Two of these tools are PC-Lint, used for uncovering defects contained in C and C++ code, and JiveLint, used for inspecting Java™ code. PC-lint checks C/C++ source code for bugs, glitches, inconsistencies, non-portable constructs, and redundant code. JiveLint looks for unused code and variables, switch blocks without a default case, if a class overrides Object.equals( ) but not Object.hashCode( ), if the code uses == to compare Strings instead of equals( ), etc. The purpose of “linting” your code is to uncover potential problems prior to integration or porting, or to reveal unusual constructs that may cause subtle, hard-to-find errors; however, linting does not provide any evaluation of the creator of the software. An organization may be very diligent in conducting pre-production code checking, such as linting the code, code review sessions, etc., but without an effective tool to assess the skill level (and weaknesses) of the developers of the code, the same coding errors will occur again and again.
Orthogonal Defect Classification (ODC) is another useful tool which provides a method of evaluating the production and associated testing processes related to a given software artifact. For details regarding ODC see “Orthogonal Defect Classification,” Ram Chillerage, et. al., IEEE Transactions on Software Engineering, vol. 18 no. 11, November 1992 and “Evaluating Software Development Objectively,” Kathryn A. Bassin, Theresa Kratschmer, P. Santhanam, IEEE Software November/December 1998. Although ODC can provide indications of how a given software artifact is deficient and how the production and testing procedures should be modified, it does not provide a multidimensional assessment of the creator.
In fact, no such multidimensional assessment is provided for software code developers (software engineers) based on their work, either per artifact, or on a compilation of their work. Certification (e.g., Novel System Administrator certification) has become common in the industry and many employers require some sort of certification prior to hiring a developer. Certification, however, is limited to providing an indication that an individual understands, or at a minimum has passed a test regarding, a given topic. It does not provide a comprehensive assessment of the given individual's strengths and weaknesses with regard to the topic.
Many types of professional athletes have multidimensional assessments based on their work: ice skaters are judged for their skill, level of difficulty, and creativity, an assessment provided for each given performance. Each score is frequently expressed as a number between 1 and 10, each value determined by the opinion of one or more judges (subjectively). Baseball players are judged based on their performance: e.g., times-at-bat, errors, hits, and runs-batted-in. These values are maintained both for individual games, set of games and cumulatively for a given player's entire career. The values are specified numerically, both using integers (e.g., 200 home runs) and decimals (e.g., 0.300, i.e., a hit 3 out of 10 times).
The software industry has grown in complexity and corporations spend a great deal on software development, yet there exists no comprehensive method of assessing the skill level of software developers. Therefore, there is a need for a system and method that overcomes the aforementioned shortcomings.